Miles Sound System SDK 7.2a

DOS Sound Driver Architecture

Discussion

MSS-compatible digital sound drivers are essentially "tiny model" real-mode .COM files with the file suffix .DIG. MIDI interpreter drivers are similar in structure, and bear the standard suffix .MDI.

MSS drivers are loaded into memory by the application at runtime -- not as TSR programs. The area of memory occupied by a MSS driver must be paragraph-aligned (that is, the lower four bits of its offset address must be 0). MSS loads these sound drivers into the lower 1MB of physical memory, which is allocated under DPMI with a call to INT 31H Function 100H. MSS then communicates with these drivers through a standard interrupt-based calling mechanism.

The standard MSS communications interrupt is INT 66H. To call a sound driver function, the AX register must be set to the desired function number, the BX register must contain the desired driver number (see below), and an INT 66H call must be performed. Function numbers 400H - 4FFH are reserved for use by .DIG digital sound drivers, while functions 500H - 5FFH are assigned to .MDI music drivers. Functions 300H - 3FFH are initialization functions common to both driver types. Any functions not handled by a given MSS driver (including, for example, DIGPAK and MIDPAK driver calls, which share INT 66H with MSS) should be passed down to the previous INT 66H handler.

Up to 65,536 .DIG and .MDI drivers may be loaded simultaneously by the application, if desired, to provide true "surround-sound" effects with multiple sound cards. When making an MSS driver call, the BX register should contain the driver number specifying which driver in the INT 66H chain should handle the call. Driver numbers start at 0 and increase by 1 for each MSS driver loaded by the application.

Interrupts are disabled by default during execution of all driver calls, to guard against data coherency problems. Sound driver functions which require interrupts to be enabled, or which need large amounts of processing time, must explicitly enable interrupt service with an STI instruction. This should not be done without careful consideration of asynchronous data and hardware-state coherency issues. The CPU interrupt state is automatically restored upon exiting from a sound driver function.

Although the MSS API layer requires an 80386-class CPU, sound drivers should be developed for compatibility with all Intel processors including the 8086 and 80286, when possible. This will help prevent problems with specialized or embedded applications which may be developed with MSS.

In summary, MSS driver calls use the following form. All registers not used to return data from a given function are preserved, with the exception of AX.

AX: Input: 300H-3FFH (All drivers), 400H-4FFH (.DIG driver functions), 500H-5FFH (.MDI driver functions). Output: Status or returned value (1 is success, 0 is failure, -1 is not supported).

BX: Input: Driver number.

To provide a general "skeleton" template for MSS driver development, the MASM/TASM-compatible modules MSS_DIG.INC and MSS_MDI.INC are supplied as part of the MSS DDK.

Every MSS driver's binary image, regardless of driver type, begins with a structure of type VDI_HDR. This structure provides information which MSS needs in order to link the driver into the INT 66H chain and perform any necessary initialization tasks. The VDI_HDR structure also contains the driver number value which enables the driver to respond to calls made to it, while passing others down the INT 66H chain.

As defined in MSS.H, the Driver Header Table for .MDI and .DIG drivers uses the VDI_HDR structure.

Group: MSS Device Development Kit for DOS Sound Drivers
Related Structures: VDI_HDR